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Abstract —With the emergence of connected and autonomous 
vehicles, sensors are increasingly deployed within cars to support 
new functionalities. Traffic generated by these sensors congest 
traditional intra-car networks, such as CAN buses. Furthermore, 
the large amount of wires needed to connect sensors makes it 
harder to design cars in a modular way. To alleviate these limita¬ 
tions, we propose, simulate, and implement a hybrid wired/wire¬ 
less architecture, in which each node is connected to either a 
wired interface or a wireless interface or both. Specifically, we 
propose a new protocol, called Hybrid-Backpressure Collection 
Protocol (Hybrid-BCP), to efficiently collect data from sensors in 
intra-car networks. Hybrid-BCP is backward-compatible with 
the CAN bus technology, and builds on the BCP protocol, 
designed for wireless sensor networks. Hybrid-BCP achieves high 
throughput and shows resilience to dynamic network conditions, 
including adversarial interferences. Our testbed implementation, 
based on CAN and ZigBee transceivers, demonstrates the load 
balancing and routing functionalities of Hybrid-BCP and its 
resilience to DoS attacks. We further provide simulation results, 
obtained with the ns-3 simulator and based on real intra-car RSSI 
traces, that compare between the performance of Hybrid-BCP 
and a tree-based data collection protocol. Notably, the simulations 
show that Hybrid-BCP can achieve the same performance as the 
tree-based protocol while reducing the radio transmission power 
by a factor of 10. 

1. Introduction 

The conventional intra-car communication model, in which 
sensors communicate with Electronic Control Units (ECUs) 
via CAN buses, faces several limitations. Eirst, the increasing 
amount of wires required to connect sensors to the intra-car 
network results in fuel inefficiency and complicates car design 
and maintenance [1]. Second, new sensors generates additional 
traffic and increases the likelihood of congestion on the CAN 
bus. Last, since the CAN protocol is based on message priority, 
it is vulnerable to Denial-of-Service (DoS) attacks generated 
by high-priority messages [2]. 

To alleviate limitations of intra-car wired networks, we pro¬ 
pose in this work a hybrid wired/wireless network architecture 
for supporting intra-car communication. A key goal in this 
context is to achieve reliable and efficient delivery of packets 
from the sensors to a sink (ECU), a task also known as data 
collection. 

The design of such a hybrid network brings up several 
research issues. The first issue is how to implement routing. 
Eor instance, in the hybrid network of Eig. 1, packets destined 
from node 2 to the sink can be routed either through node 7 
or node 9. Which node should be chosen as the next hop? 

The second issue is how to implement load balancing. Eor 
instance, node 10 can communicate with the sink either on 



Eig. 1: A 15-node intra-car hybrid wired/wireless network. 
Each node is connected to either a wired interface or a wireless 
interface or both. The data packets of the sensor nodes (1-14) 
need to be delivered to the sink (node 0). 

the wired interface or the wireless interface. Which interface 
should be used? 

The third issue is how to deal with contention from other 
nodes and (possibly malicious) interferences. Eor instance, 
how should node 10 react if node 4 is contending on the 
wired link? And what happens if an adversary performs a DoS 
attack? 

In light of these challenges, we define the following objec¬ 
tives for designing a collection protocol for hybrid intra-car 
networks: 

• Load balancing. The protocol should balance packet 
transmissions over available interfaces. 

• Routing. In the absence of a direct communication link 
between a sensor node and the sink, the protocol should 
deliver the packets of the sensor node in a multi-hop 
fashion. 

• Robustness. The protocol should achieve reliable data 
collection even when link qualities degrade (e.g., due to 
contention, interferences, or DoS attacks). 

• Backward-compatibility The protocol should not require 
the replacement of existing technology (e.g., CAN buses) 
in vehicles. 

Routing protocols based on the construction and mainte¬ 
nance of end-to-end routes adapt poorly to intra-car wireless 
channel conditions that typically experience deep fading and 
high variability [3]. 

To address these issues, we propose a new data collection 
protocol for hybrid intra-car networks, called Hybrid-BCP. 
Hybrid-BCP belongs to the class of backpressure algorithms 
[3], which have theoretically been proven to be throughput- 
optimal. 
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Hybrid-BCP does not calculate end-to-end routes. Rather it 
relies on a distributed computation of backpressure weights. 
Each node maintains a backpressure weight on each interface 
for each of its neighbors, based on the link quality and the 
differential of the queue lengths. For each incoming packet, 
a node selects the interface/neighbor combination with the 
highest positive backpressure weight as the next hop. If all 
the backpressure weights are negative, then the node stores 
the packet in its queue and waits until one of the backpressure 
weights becomes positive. 

We implement Hybrid-BCP on a real testbed, composed of 
CAN and ZigBee transceivers, and evaluate its performance. 
Our testbed experiments demonstrate the load balancing and 
routing functionalities of Hybrid-BCP. The results show that 
Hybrid-BCP improves throughput under DoS attacks on the 
CAN bus by a factor of 10. They also show that Hybrid-BCP 
is robust to jamming attacks on wireless links. 

We further implement Hybrid-BCP in ns-3 for the purpose 
of simulating a larger network. We compare Hybrid-BCP with 
a tree-based collection protocol, which we refer to as Hybrid- 
Collection Tree Protocol (Hybrid-CTP). Hybrid-CTP relies on 
the computation and update of end-to-end routing metrics at 
each node. 

For the simulations, we use real RSSI (received signal 
strength indication) traces collected in an intra-car environ¬ 
ment [4]. The simulation results demonstrate that Hybrid- 
BCP achieves higher reliability than Hybrid-CTP if both 
protocols use the same power transmission (e.g., 95% vs 88%). 
Conversely, Hybrid-BCP can reduce the radio transmission 
power by a factor of 10 and still achieve the same reliability 
as Hybrid-CTP. 

We summarize the contributions of this paper as follows: 

• We design a new protocol, Hybrid-BCP, for data collec¬ 
tion in intra-car hybrid wired/wireless networks. 

• We build a real testbed for evaluating the performance 
of Hybrid-BCP. The tests demonstrate the load balanc¬ 
ing and routing functionalities of Hybrid-BCP and its 
resilience to DoS attacks. 

• We implement Hybrid-BCP and Hybrid-CTP in the ns- 
3 simulator, and compare their performance in terms of 
reliability for different transmission powers. 

The rest of the paper is organized as follows. Section II 
reviews related work on hybrid wired/wireless networks, load 
balancing algorithms for multiple interfaces, and collection 
protocols. Section III describes the Hybrid-BCP protocol and 
its software implementation. Section IV and V provide per¬ 
formance evaluation of Hybrid-BCP in testbed experiments 
and simulations, respectively. Finally, Section VI concludes 
the paper and discusses future research directions. 

H. Related WORK 

A. Hybrid wired/wireless networks 

Much of the existing work on hybrid wired/wireless net¬ 
works assumes that all the devices (except for bridges or 
relays) are connected to either a wired interface or a wireless 
interface but not both. 

For instance, [5] implements a hybrid wired/wireless net¬ 
work for greenhouse control and management using CAN and 


Algorithm 1 BCP 

1: Compute backpressure weight Wij for each neighbor j 
2: Find the neighbor j* such that j* = argmax^ Wij 
3: if > 0 then 
4: Transmit a packet to j* 

5: Update ETXi^j* and IZi^j* 

6: else 

7: Wait for a reroute period and go to line 1 

8 : end if 
9: Go to line 1 


ZigBee transceivers. In that system, the central controller and 
a number of wireless bridges are connected to a bus. The 
bridges receive data from wireless sensors and forward them 
to the controller. The work in [6] conducts a feasibility study 
of a hybrid wired/wireless network implementation based on 
Ethernet and Bluetooth. In the implementation, sensors have 
either a wired or a wireless interface while the sinks are 
connected to a bus. A bridge node communicates between the 
wireless nodes and the wired nodes. Similar hybrid network 
structures can be found in [7,8], where wireless nodes commu¬ 
nicate with wired nodes through access points. In the hybrid 
wired/wireless models of [9,10], a number of base stations 
are interconnected with high-bandwidth wired links and they 
serve as relays for the wireless nodes. 

In contrast to the above work, Hybrid-BCP allows any node 
(sensors and ECUs) to be connected to either type of interfaces 
or both. 

B. Load balancing 

There exist several protocols for aggregating bandwidth 
and performing end-to-end load balancing. These protocols 
are implemented at the transport layer or above, and rely on 
protocols at lower layers to provide the routing functionality. 

For instance. Multipath TCP (MPTCP) [11] uses multiple 
TCP paths to increase the throughput of data transfer. The 
earliest delivery path first (EDPF) [12] estimates the packet 
delivery time on severals path and schedules packets on the 
path with the shortest delivery time. The work in [13] adds 
to EDPF by incorporating transmission rates and losses in the 
estimation of the delivery time of packets. Other algorithms 
based upon EDPF includes [14-16]. 

Different from the above work, Hybrid-BCP provides a joint 
load balancing and routing solution. 

C. Collection protocols 

Collection protocols are routing protocols designed specifi¬ 
cally for routing data from sensor nodes to a central collection 
node. There exist two well-known collection protocols in 
wireless sensor networks. The first one is the Collection Tree 
Protocol (CTP) [17]. CTP establishes a minimum-cost routing 
tree where the cost on each link cost equals the expected 
number of transmissions on that link (ETX). 

The other one is the Backpressure Collection Protocol 
(BCP) [3]. BCP derives from backpressure routing algorithms, 
which achieve optimal throughput. With BCP, nodes inde¬ 
pendently make routing decisions based on local information. 
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Routing decisions are made on a per packet basis rather than 
on a per-computed path. The work in [3] shows that BCP 
achieves higher throughput and reliability than CTP under 
dynamic network conditions (e.g., in the presence of external 
sources of interferences). 

Since Hybrid-BCP is built upon BCP, we next briefly 
review how BCP makes routing decisions. Let Qi represent 
the backlog (i.e., number of packets stored) at node i. The 
^Qi,j = Qi — Qj is the queue differential (backpressure) 
between node i and its neighbor node j. Let IZi^j be the 
estimated link rate from i to j and let ETXi^j be an estimate 
of the average number of transmissions needed to successfully 
transmit a packet over the link. According to the routing policy 
of BCP, node i calculates the backpressure weight for each 
neighbor j as follows: 

Wij = {AQij - V • ETXi^j) • 

The routing decision (i.e., the selected next hop for the 
current packet) is determined by flnding the neighbor j* with 
the highest weight. Node i then makes the forwarding decision: 
if Wij* >0, then the packet is forwarded to node j*, else the 
packet is held until the metric is recomputed. In other words, 
if the weights for all neighbor nodes are zero or negative, the 
node will do nothing but wait until the next recomputation 
(after a reroute period). A pseudo-code of BCP is given in 
Algorithm 1. 

BCP estimates ETX based on an exponential moving 
weighted average formula. Whenever a new sample of ETX 
is obtained, ETX is updated as follows: ETX new = 
aETXoid + (1 “ a)ETX. The default value of a is 0.9. 
The link rate is calculated as the reciprocal of the packet 
transmission time (the time elapsing from the first transmission 
to the reception of an ACK), and the estimated link rate IZ is 
updated according to an exponential moving weighted average 
formula similar to that used for ETX. 

III. Hybrid-BCP 

In this section, we describe the protocol design of Hybrid- 
BCP and its software implementation. 

A. Protocol design 

Hybrid-BCP can be viewed as two BCP algorithms running 
in parallel, with one algorithm handling the wired interface 
(e.g., CAN) and the other one handling the wireless interface 
(e.g., ZigBee). 

Next, we describe the handler of interface /, where / G 
{W^WL} {W represents the wired interface and WL rep¬ 
resents the wireless interface). Let be the estimated 

- 1 

link rate from i to j over interface / and let ETX^^j be 
an estimate of the average number of transmissions needed to 
successfully transmit a packet over the interface. The interface 
handler of node i calculates the following backpressure weight 
for each neighbor j on interface / as follows: 

= (AQi,,- - y ■ ETXX) ■ IZUj. 

Let j* denote the neighbor with the highest weight on the 
wired interface, i.e., j* = argmax^rc^^. Let /c* denote the 


Algorithm 2 Hybrid-BCP 
1: procedure Wired_interface_handler 
2: while Qi > 0 do 

3: Wire_bBsy ^ false 

4: Compute the backpressure weight wfj for 

each neighbor j on the wired link 
5: Find the neighbor j* such that j* = 

arg max^- wfj 

6: if > 0 and (Wireless_bBsy = true or 

wfj. > then 

7: Wire_bBsy ^ true 

8: Transmit one packet to j* over the wired 

interface 

9: Update ETX^j^ and 

10: Wire_bBsy ^ false 

11: else 

12: Wait for a reroute period 

13: end if 

14: end while 

15: end procedure 

16: 

17: procedure Wireless_interface_handler 

18: while Qi > 0 do 

19: Wireless_busy ^ false 

20: Compute the backpressure weight for 

each neighbor k on the ZigBee links 
21: Find the neighbor /c* such that /c* = 

WL 

arg max;. 

22: if > 0 and (Wire_bBsy = true or 

>w^j.) then 

23: Wireless_bBsy ^ true 

24: Transmit one packet to /c* over the wireless 

interface 

- lY L —W L 

25: Update ETX^^j^. and 

26: Wireless_bBsy G- false 

27: else 

28: Wait for a reroute period 

29: end if 

30: end while 

31: end procedure 


neighbor with the highest weight on the wireless interface, 
i.e., k* = arg maxj^ . 

A higher backpressure weight represents a link of higher 
quality and a neighbor with less backlog. A necessary condi¬ 
tion for the wired interface handler to transmit a packet to 
neighbor j* is that > 0. When both the wired and 

wireless interface handlers are idle, an additional condition 
is that the weight of the wired interface is the larger one, 
i.e., LuJj:, > If one of these conditions is not satisfled, 

then the wired interface handler waits for the next computation 
of backpressure weights. Similar conditions apply for the 
wireless interface handler. Algorithm 2 provides a pseudo-code 
of Hybrid-BCP. Table I summarizes the scheduling procedure 
of Hybrid-BCP. 
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Operation 

> 0 

< 0 

Transmit the next packet to neighbor j* on 
the wired link. 

< 0 

> 0 

Transmit the next packet to neighbor fc* on 
the wireless link. 

< 0 

< 0 

The next packet is not transmitted. 

> 0 

> 0 

If both interface handlers are idle, the next 
packet is scheduled on the link with the 
larger weight. If one of the interface han¬ 
dlers is busy, the next packet is transmitted 
on the interface which is idle. 


TABLE I: Packet transmission scheduling of Hybrid-BCR 


Wired Forwarding Engine I Wireless Forwarding Engine 


Packet Sending Procedure ■ Packet Sending Procedure 


Packet Receiving Procedure I Packet Receiving Procedure 


Routing Engine 


Beacon Controller 


Wired Communication API I Wireless Communication API 


Fig. 2: The software architecture of Hybrid-BCR 


B. Software implementation 

The software implementation of Hybrid-BCP consists of a 
routing engine, a wired forwarding engine, a wireless forward¬ 
ing engine and a beacon controller (see Fig. 2). 

The routing engine is responsible for calculating the back¬ 
pressure weights for each neighbor and interface. It updates 
and maintains the routing table. 

The forwarding engine is responsible for scheduling packet 
transmissions and handling packet receptions. It is further 
composed of a packet sending procedure and a packet receiv¬ 
ing procedure: the packet sending procedure runs the interface 
handler described in Algorithm 2, while the packet receiving 
procedure handles ACK packets and provides information for 
the routing engine to update the routing table. 

The forwarding engine also keeps a count of transmissions 
for each packet. When the packet sending procedure transmits 
a packet on the interface, it waits to receive an ACK from 
the next hop until an ACK timeout. If an ACK is not received 
before the timeout, the packet sending procedure retransmits 
the packet on the interface. 

Hybrid-BCR utilizes beacon messages to propagate back¬ 
pressure information from a node to its neighbors. The beacon 
controller is responsible for broadcasting beacon messages on 
all available interfaces. 

IV. Experiments 

In this section, we demonstrate the load balancing and 
routing functionalities of Hybrid-BCR in the testbed. We also 
show that Hybrid-BCR can be used to protect against DoS 
attacks on the CAN bus and wireless jamming attacks. 


ACK timeout for CAN link 

30 ms 

ACK timeout for ZigBee link 

80 ms 

Reroute period 

50 ms 

Beaconing period 

1500-2000 ms 

Queue size 

48 


TABLE II: Rarameters in the implementation of Hybrid-BCR 
for the testbed. 

A. Performance metrics 

Before presenting the experiments, we provide the definition 
of metrics for evaluating the performance of Hybrid-BCR. 

Suppose a test lasts for T seconds. Let N denote the total 
number of generated packets. Let Nu denote the number of 
delivered packets, excluding packet duplicates, and let Sd 
represent the set of the uniquely delivered packets. 

The delivery rate is defined to be the percentage of packets 
that are delivered, i.e., ^ • 100%. The throughput is defined 
to be the number of unique packets delivered to the sink per 
second, i.e., ^ pkts/sec. The delay of a packet Di is defined 
as the time elapsing from its generation at the source node 
to its delivery at the sink. The average delay is calculated as 

7 ^ ^ieSd 

B. Experimental setup 

We build a hybrid CAN/ZigBee network to test Hybrid- 
BCR. We use VN1610 CAN interfaces 118], manufactured by 
Vector Informatik GmbH, as CAN transceivers. We use TelosB 
motes 119] as ZigBee transceivers. The CAN bus is configured 
to operate at the rate of 33,333 baud. The transfer rate of a 
ZigBee transceiver is 250 Kb/s. 

To emulate a node (a sensor or an ECU), we use a laptop 
to which one or both types of transceivers are connected. 
The laptop runs a Windows Rresentation Foundation (WRF) 
application 120] to manage the interfaces. Hybrid-BCR is 
implemented in C#, as a component of the WRF application. 

The first set of tests is conducted on the networks A, B, 
and C, whose topologies are shown in Fig. 3. Fig. 4 shows 
the testbed setup of network C. 

We choose the ACK timeout for a CAN/ZigBee link to be 
slightly larger than the round trip time (RTT) of the link under 
light load conditions. The RTT of a CAN link is around 15 
ms and that of a ZigBee link ranges from 50 ms to 70 ms. 
The ZigBee link has a higher RTT than a CAN link because 
ZigBee is based on CSMA/CA (Carrier Sense Multiple Access 
/ Collision Avoidance) while CAN is based on CSMA/CD 
(Carrier Sense Multiple Access / Collision Detection). 

Every time a beacon packet is transmitted, Hybrid-BCR 
waits for a beaconing period to transmit a new beacon packet. 
The beaconing period is chosen to be sufficiently large so that 
beacon packets do not cause congestion on the links. It is also 
uniformly randomly selected within a range of possible values 
to avoid possible synchronization of beacon packets between 
different nodes and contention on the links. Table II lists the 
parameters used in the Hybrid-BCR implementation. 

In the tests, each sensor node periodically generates data 
packets and transfers them to Hybrid-BCR, which delivers the 
packets to the sink. Sensor nodes generate packets at the same 
rate. Each test is run for five times to obtain an average and a 
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Network A 

ZigBee 


Network B 


ZigBee 


Node 2 


Node 1 

CAN bus 

Node 0 




Network C 




Packet generation rate (pkts/sec per node) 
(a) Delivery rate versus packet generation rate. 


Fig. 3: The network topologies used for demonstrating the 
load balancing and routing functionalities of Hybrid-BCP on 
the testbed. 



Fig. 4: Testbed setup for network C. 



95% confidence interval for the metrics. Each run lasts from 
three to five minutes. 

C. Load balancing 


(b) Percentage of packets delivered over the CAN/ZigBee interfaces 
on network B. 

Fig. 5: Performance of Hybrid-BCP on network A (CAN only) 
and network B (hybrid). 


To demonstrate the load balancing functionality of Hybrid- 
BCP, we perform tests on network A (a CAN network) and 
network B (a hybrid CAN/ZigBee network). 

Fig. 5(a) shows that at a packet generation rate of 80 
pkts/sec, Hybrid-BCP improves the delivery rate of node 1 
from 80.15% to 99.63% thanks to the additional wireless link. 
Moreover, the delivery rate of node 2 also improves, from 
78.99% to 84.82%. This is because Hybrid-BCP transmits 
a fraction of packets of node 1 on the ZigBee link for the 
purpose of load balancing, hence reducing MAC contention 
on the CAN bus. 

In network B, when the packet generation rate of node 1 is 
low, Hybrid-BCP schedules most of its packets on the CAN 
interface, as shown by Fig. 5(b). This is because the CAN link 
has a smaller RTT and thus a higher link rate than the ZigBee 
link. When the packet rate increases, the backlog of node 1 
grows and Hybrid-BCP starts scheduling packet transmissions 
on the ZigBee link. When the packet rate reaches a certain 
threshold, the percentages of packets delivered through the 
CAN and ZigBee interfaces do not change further because 
both links are saturated. 



Fig. 6: Delivery rate versus packet generation rate of Hybrid- 
BCP on network C. Hybrid-BCP can successfully route the 
packets of node 2 to the sink via node 1. 

D. Routing 

To demonstrate the routing functionality of Hybrid-BCP, we 
perform tests on network C. In network C, there is no direct 
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(a) DoS attacks on the CAN bus. 




(b) DoS attacks on the hybrid net¬ 
work. 



Jammer 


\7 



Y 


Y 

Nodel 


Node 0 


(c) Wireless jamming on the Zig- (d) Wireless jamming on the hy- 
Bee link. brid network. 

Fig. 7: DoS attacks on the CAN bus and wireless jamming 
attacks. 


communication link between node 2 and the sink. The packet 
delivery rates of node 1 and node 2 are plotted in Fig. 6. The 
results show that the delivery rate of node 2 is 98.93% at a 
packet generation rate of 20 pkts/sec. Thus, Hybrid-BCP can 
successfully route packets from node 2 to the sink via node 
1. The ns-3 simulations in Section V demonstrate the routing 
functionality of Hybrid-BCP in a larger hybrid network. 

E. Robustness 

1) DoS attacks on CAN 

The CAN protocol is a priority-based protocol: a high- 
priority message gets transmitted ahead of a low-priority 
message. Previous work in [21] shows that the injection of 
malicious CAN messages can be done by remotely compro¬ 
mising and controlling nodes on the bus (via the radio, the tire 
pressure monitoring system or the Bluetooth component). In 
this section, we evaluate the effects of such DoS attacks on a 
legitimate node that has not been compromised. 

We implement a DoS attack by having an attacker trans¬ 
mit high-priority messages on the CAN bus, at a rate of 
300 pkts/sec. We compare Hybrid-BCP to the native CAN 
protocol, a transmission scheme in which a legitimate node 
periodically generates data packets and transfers them to the 
CAN transceiver. The performance of the native CAN protocol 
is tested in the network of Fig. 7(a) and the performance of 
Hybrid-BCP is tested in the network of Fig. 7(b). 

Fig. 8(a) shows the average delay of packets by node 1 
under the native CAN protocol and Hybrid-BCP. We see that 
the average delay of the native CAN protocol under the DoS 
attack reaches high values exceeding 3 sec (e.g., 3,810 ms at a 
packet generation rate of 15 pkts/sec by a legitimate node). The 
low-priority legitimate node is almost starved and must wait 
for a long time between each successful transmission. This 



(a) Average delay of the legitimate node versus its packet generation 
rate. 
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Packet generation rate (pkts/sec per node) 
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(b) Delivery rate of the legitimate node versus its packet generation 
rate. 



(c) Throughput of the legitimate node versus its packet generation 
rate. 

Fig. 8: Performance of the native CAN protocol and Hybrid- 
BCP under DoS attacks on the CAN bus. 


result indicates that the DoS attack dramatically increases the 
MAC delay of a legitimate node. 
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> 

Q 



Ethernet data rate 

4Mbps 

Wi-Fi standard 

802.1 Ib 

Wi-Fi mode 

Ad hoc 

Wi-Fi data rate 

DSSS IIMbps 

Ethernet ACK timeout of Hybrid-BCP 

I ms 

Wi-Fi ACK timeout of Hybrid-BCP 

2 ms 


TABLE III: The parameters in ns-3 simulations of Hybrid- 
BCR 



Network D Network E 


(a) Delivery rate of the legitimate node versus its packet generation Fig. 10: The network topologies used for demonstrating the 
rate. load balancing functionality of Hybrid-BCP in simulations. 



(b) Throughput of the legitimate node versus its packet generation 
rate. 

Eig. 9: Performance of the native ZigBee protocol and Hybrid- 
BCP under wireless jamming attacks. 


On the other hand, under the same DoS attack, Hybrid-BCP 
achieves higher packet delivery rate and higher throughput 
than the native CAN protocol, as shown in Pig. 8(b) and 
8(c). More specifically, Hybrid-BCP achieves a throughput of 
19.87 pkts/sec at a packet generation rate of 20 pkts/sec by a 
legitimate node, more than ten times higher than that of the 
native CAN protocol. This gain is achieved because Hybrid- 
BCP measures a high ETX on the CAN link and schedules 
packet transmissions on the ZigBee link instead. These results 
demonstrate that Hybrid-BCP can protect the CAN bus against 
DoS attacks. 

2) Wireless jamming 

In the wireless jamming tests, a wireless jammer performs 
protocol-compliant jamming attacks on the ZigBee link. The 
jammer periodically generates packets and broadcasts them 
on the ZigBee link. In our tests, the rate the wireless jammer 
generates packets is 100 pkts/sec. We compare Hybrid-BCP 
with the native ZigBee protocol, which simply periodically 


generates data packets and sends them on the wireless link to 
the sink. The native ZigBee protocol is tested in the network 
of Pig. 7(c) and the hybrid wired/wireless protocol is tested 
in network of Pig. 7(d). 

Comparisons between the delivery rate and throughput of 
the native ZigBee protocol and those of Hybrid-BCP are 
shown in Pig. 9(a) and Pig. 9(b). The results show that under 
wireless jamming, the delivery rate of the ZigBee protocol is 
at most 54.90% at a packet generation rate of 50 pkts/sec, 
while Hybrid-BCP achieves a delivery rate of 99.95%. 

V. Simulations 

In this section, we provide performance evaluation of 
Hybrid-BCP in ns-3 simulations. We demonstrate the load 
balancing functionality of Hybrid-BCP under a higher wireless 
data rate. We also compare Hybrid-BCP to a tree-based 
routing protocol in a simulated intra-car hybrid wired/wireless 
network. 

A. Simulation setup 

In the ns-3 simulations, we use the built-in Ethernet and 
Wi-Pi ns-3 libraries to simulate wired and wireless links. 
To emulate the CAN/ZigBee links in the real testbed, we 
configure the ns-3 simulations such that the Wi-Pi link has 
a higher rate but a larger RTT than the Ethernet link. Table III 
describes the simulation configuration and the parameters of 
Hybrid-BCP. The simulation configuration is used throughout 
the simulations except for Section V-B, in which we compare 
the performance of Hybrid-BCP under different Wi-Pi rates. 
Each simulation is run for five times to obtain an average and 
a 95% confidence interval for the metrics. 

B. Load balancing 

With the extra wireless link having a higher data rate, 
Hybrid-BCP can perform load balancing to aggregate more 
bandwidth. We run simulations of Hybrid-BCP in three sce¬ 
narios: (1) network A; (2) network B with Wi-Pi rate equal 
to 11 Mbps (802.11b); (3) network B with Wi-Pi rate equal 
to 18 Mbps (802.11a). The packet delivery rates under the 
three scenarios are plotted in Pig. 11. At a packet generation 






































Fig. 11: Delivery rates of Hybrid-BCP on network D (Eth¬ 
ernet only) and network E (hybrid) in ns-3 simulations. The 
throughput improvement by load balancing of Hybrid-BCP is 
more significant as the wireless data rate gets higher. 

rate of 6,000 pkts/sec, Hybrid-BCP achieves a delivery rate 
of 61.71% when there is no extra wireless link. With an extra 
Wi-Fi link at the rate of 11 Mbps, the delivery rate is increased 
to 82.25%. The delivery rate is further increased to 99.90% 
when the Wi-Fi data rate is increased to 18 Mbps. The results 
show that the benefits of load balancing by Hybrid-BCP are 
more significant as the wireless data rate gets higher. 

C. Routing and robustness 

We use the intra-car RSSI traces measured from real exper¬ 
iments to simulate a 15-node intra-car hybrid wired/wireless 
network (the topology is shown in Fig. 1). In the hybrid 
network, the sink is on the driver seat, three sensors are 
placed in the engine compartment, four sensors are respec¬ 
tively attached to the four wheels, three sensors are placed 
on passenger seats and the rest placed on the chassis. We 
use Hybrid-CTP, a variant of CTP designed for the hybrid 
network (see the appendix for description of the protocol), as 
a tree-based routing protocol to compare with Hybrid-BCP. 
In the simulations, each sensor periodically generates and 
transfers data packets to the underlying protocol (Hybrid-BCP 
or Hybrid-CTP), which routes the packets to the sink. 

Fig. 12(a) and 12(b) show the packet delivery rate and 
average hop count of Hybrid-BCP and Hybrid-CTP under two 
different radio power levels. Fig. 12(a) shows that when the 
radio transmission power is -27 dBm, Hybrid-BCP achieves 
higher packet delivery rate. At a packet generation rate of 
20 pkts/sec, Hybrid-BCP achieves a delivery rate of 95% 
while Hybrid-BCP achieves a delivery rate of 88.66%. This 
shows that Hybrid-BCP outperforms Hybrid-CTP in the intra¬ 
car hybrid network and is thus more robust to the dynamic 
intra-car wireless links. When the radio transmission power 
is increased to -17 dBm, the delivery rate of Hybrid-CTP 
improves but is still lower than Hybrid-BCP at -27 dBm (e.g., 
at a packet generation rate of 30 pkts/sec). This indicates that 
Hybrid-BCP can consume less power to achieve the same 
reliability performance, and thus is more power efficient. 



(a) Delivery rate versus packet generation rate. 



(b) Average hopcount versus packet generation rate. 

Fig. 12: Performance of Hybrid-BCP and Hybrid-CTP in a 
simulated 15-node intra-car hybrid wired/wireless network. 
Hybrid-BCP achieves comparable reliability with Hybrid-CTP 
even when reducing the radio power by 10 dBm. 

The routing functionality of Hybrid-BCP is further demon¬ 
strated by the statistics of number of hops in Fig. 12(b). 
The figure shows that when the radio transmission power 
increases, the average number of hops decreases, which is to 
our expectation. 

VI. Conclusion 

In this paper, we designed and implemented Hybrid-BCP 
as a joint load balancing and routing solution for data 
collection in intra-car hybrid wired/wireless networks. It is 
backward-compatible with existing intra-car wired network 
since no modification is needed on the CAN protocol. We 
demonstrated the load balancing and routing functionalities of 
Hybrid-BCP in testbed experiments. We showed that Hybrid- 
BCP can be used to alleviate the impact of DoS attacks 
on the CAN bus. Through simulations of intra-car hybrid 
networks based on dynamic RSSI traces collected from real 
experiments, we showed that Hybrid-BCP can use less radio 
transmission power to achieve the same reliability as the 
tree-based collection protocol. Additional simulation results 
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Algorithm 3 Hybrid-CTP 
1: procedure Wired_interface_handler 
2: while Qi > 0 do 

3: Compute the ETXfj for each neighbor j on 

the wired link 

4: Find the neighbor j* such that j* = 

arg min^ ETXf^ 

5: if ETXj^* < ETXf^* + T then 

6: Transmit one packet to j* over the wired 

interface 

7: Update ETxY -^ j - and ETXi 

8 : else 

9: Wait for a reroute period 

10: end if 

11: end while 

12: end procedure 

13: 

14: procedure Wireless_interface_handler 
15: while Qi > 0 do 

16: Compute the ETXf^j/^ for each neighbor k 

on the wireless link 

17: Find the neighbor k* such that k* = 

argmin^ ETX '^^^ 

18: if ETX ^^' < ETX ^’ + T then 

19: Transmit one packet to /c* over the wireless 

interface 

20: Update 'WxYX and ETXi 

21: else 

22: Wait for a reroute period 

23: end if 

24: end while 

25: end procedure 


showed that the improvement on throughput by Hybrid-BCP 
is more significant with a wireless link of higher data rate. 

For the sensors in the car, different sensors have different 
priority on transmitting their messages. It would be useful 
to extend Hybrid-BCP to incorporate a priority-based load 
balancing and routing scheme. The priority information needs 
to be incorporated in the protocol header and the protocol 
should be devised to reasonably make use of this information. 
It is also interesting to extend Hybrid-BCP to support data 
collection with multiple sinks, where each sensor is assigned 
a specific sink. We leave these as future works. 

Appendix 

Protocol design of Hybrid-CTP 

In this section, we describe Hybrid-CTP, a variant of CTP 
designed for data collection in hybrid wired/wireless networks. 

The same as Hybrid-BCP, Hybrid-CTP has two procedures 
handling the wired and wireless interfaces, respectively. Sup¬ 
pose for node i, node j is a neighbor on interface /, where 
/ G {W^WL} {W represents the wired interface and WL 
represents the wireless interface). Let ETX^^j denote an 
estimate of the average number of transmissions needed to 
successfully transmit a packet from i to j over interface /. 

Each node i records its end-to-end path cost to the sink. 


denoted by ETXi. To obtain ETXi, node i first calculates 
the path cost through interface / via node j as follows: 

ETXC = ETXj + ETxE. 

The minimum path cost from node i to the sink node through 
interface / is ETXf = min^ ETX- j. 

Then node i calculates its path cost to the sink by: 

ETXi = mm{ETXj^\ETXj^^'’}. 

The path cost information is propagated to neighbors by 
beacon messages, the same as the backpressure information 
in Hybrid-BCP. The sink broadcasts path cost of zero. 

In Hybrid-CTP, the wired interface handler schedules a 
packet transmission when ETXf^* < ETXj^^* + T, where 
T is a positive integer (set to two in our implementation). 
Similarly, the wireless interface handler schedules a packet 
transmission when ETXj^^* < ETXf^* + T. Therefore, 
when ETXf^* is much smaller than ETXj^^* , only the 
wired interface handler will schedule packet transmissions. 
This could happen either when the wireless link quality is bad 
or when all the neighbors on the wireless link select this node 
as their next hop. When ETXf^* and ETX^^* are close 
to each other, both interface handlers will transmit packets. 
Algorithm 3 provides a pseudo-code of Hybrid-CTP. 
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